Access control systems provide mechanisms for regulating access by users to resources in data processing systems. Access control is fundamental for enforcing security and privacy requirements in data processing systems, protecting system resources such as files, applications, databases etc., against unauthorized access by internal or external system users. In simple terms, access control involves the assignment of authorizations to users, whether individuals or groups, specifying the extent of users' permitted access to resources, and the evaluation of requests for access to resources to check for appropriate authorization, allowing enforcement of access restrictions as required in a given system. Authorizations form the basis of an overall access control policy which specifies the set of access constraints for a given system. The access control policy is defined by some form of data structure, which may have a number of component data structures, stored in system memory. In a typical access control scenario, a user sends an access request to the system component, such as a web server or file server, which protects the resource to which access is requested. The protecting component then sends an authorization query, asking if the user has the necessary authorization, to a decision engine of the access control system. The decision engine accesses the policy data structure to determine if the user is authorized as required, and notifies the protecting system accordingly. The access request is then permitted or denied as appropriate.
Whatever the particular architecture of the access control system, access queries are typically framed in terms of some form of subject, resource and action elements. Here, the subject element gives information about the user(s) making the request. The resource element identifies the resource(s) to which access is requested. The action element indicates the type of operation the requester wishes to perform on the resource. Authorizations are similarly expressed in the policy data structure in terms of these three basic elements, where in general an authorization indicates (explicitly or implicitly) that subject(s) X has permission to do action Y to resource(s) Z. ACL (access control list)-based access control systems provide a particular example here. Beyond this basic subject/resource/action concept, however, the access control decision logic, and the particular way in which policy is represented in policy data structures, can vary widely in access control systems.
XACML® (extensible access control markup language) is a current OASIS® (OASIS and XACML are trademarks of OASIS) initiative to develop a standard for access control systems. This standard is described in detail on the OASIS eXtensible Access Control Markup Language (XACML) Technical Committee Web page available on the oasis-open.org web site at the committees/tc home.php?wg abbrev=xacml#XACML20 page Briefly, XACML defines a language and logic for expressing and evaluating policy in an access control policy data structure, together with a query/response language, based on the simple subject/resource/action concept just described. In the XACML system, authorizations are expressed in access rules which specify the subject, resource and action elements of an authorization. These elements may define the applicable subjects, resources, and actions specifically, or may be wildcard elements (AnySubject, AnyResource, AnyAction) which match all specific elements in the corresponding category. XACML access rules have an “effect” which is either “permit” or “deny”. For example, a rule expressing authorization of a user Alice to read a data object “Order” can be defined by:
<rule effect=“Permit”> <target <subject Alice>  <resource Order>  <action Read> </target></rule>Groups of rules can be combined via logical algorithms into “policies”, and groups of policies can be similarly combined into “policy sets”. The applicability of rules, policies and policy sets to access queries is defined by “targets” which specify the set of subject, resource and action elements to which the corresponding entity applies. Thus, the overall access control policy data structure in XACML typically comprises multiple policy sets, each specifying the logical algorithms to be applied by the decision logic to policies, and, within those policies, rules, which apply to particular combinations of subject/resource/action elements. In operation, the decision logic compares the subject/resource/action triple in an access query to the targets in the data structure to identify the applicable policy sets, policies and rules, and then evaluates these accordingly. This evaluation yields a permit or deny decision in response to the access request.
The XACML system just described is an example of a “single-authorization-query” access control system. That is, the access query specifies a single authorization whose existence is to be checked for in the policy data structure, and the decision logic is designed to reach a decision based on evaluation of that authorization only. In more sophisticated access control systems, access decisions can be based on evaluation of more than a single authorization. In particular, access control policies can offer greater subtlety in the definition of authorization constraints by utilizing additional, auxiliary authorizations over and above the authorizations (“primary authorizations”) which might be specified in an access query. In general, such auxiliary authorizations and other auxiliary access conditions or restrictions may be defined explicitly or implicitly in the access control policy data structure. These auxiliary constraints must then be identified and evaluated by the decision logic as well as the primary authorization specified in the access query. An example of such an access control system is provided by the IBM® Tivoli® Access Manager system (IBM and Tivoli are registered Trade Marks of International Business Machines Corporation). This system is described in detail in “Access Control with IBM Tivoli Access Manager”, Günter Karjoth, ACM Transactions on Information and System Security (TISSEC) Vol. 6, No. 2, May 2003, pages 1-25, but a brief description will be given below to assist understanding of the invention to be described.
With the IBM Tivoli Access Manager (TAM) system, a resource is protected by an application server, known as a reference monitor, which formulates access queries based on user access requests and sends the access queries to an authorization server. Access queries request checking for authorizations based on subject, resource and action elements as described above, and are evaluated by decision logic of the authorization server against an access control policy defined in a system database. The access control policy is represented by a composite data structure which uses access control lists (ACLs) and protected object policies (POPs) associated with “protected objects”, or “objects” for short, which are logical representations of resources. Access to a resource is controlled by attaching an ACL and/or POP to the corresponding object. Authorizations are considered as permissions assigned to users, where a “permission” is a resource/action pair (i.e. permission to do action Y to resource(s) Z). Primary authorizations (those which might appear in the subject/resource/action triple of an access query) can be expressed in ACLs, but the policy data structure can also express auxiliary constraints. These auxiliary constraints may express additional authorizations or conditions associated with primary authorizations. Auxiliary constraints may be defined explicitly or implicitly in the data structure, and must be identified and evaluated along with their associated primary authorization in order to correctly express the access constraint specification of the overall access control policy. One example of an auxiliary authorization in this system is provided by the “Traverse” permission which can be assigned to users. Briefly, the system employs a hierarchical representation of resources (objects), some with associated ACLs/POPs. An object without an attached ACL inherits the nearest ACL attached to an object above it in the hierarchy. This leads to the concept of “regions”. Objects in a region are accessible if the requesting user (explicitly or implicitly) has Traverse authorization (i.e. the Traverse permission has been assigned to that user) on all objects above it in the hierarchy. Thus, in checking for a primary authorization corresponding to an access query for an object, Traverse authorizations on parent objects may need to be checked for as auxiliary authorizations. Other examples of auxiliary constraints which can be associated with a primary authorization in this system are provided by the ByPassPOP and ByPassRule authorizations which can override condition constraints expressed in a POP for example.
The great variety of access control systems on the market and in use within enterprises today makes it very difficult to provide centralized, safe and cost effective access control. Even if systems are based on the same base model such as ACLs, their policy languages and the evaluation of the authorization data is often quite different as exemplified above. US Patent Application Publication No. 2007/0056019 describes one attempt to address this type of problem. The application describes a system to implement access control requirements across dissimilar platforms, and involves capturing the requirements within a UML (Unified Modeling Language) model, translating that model into a UAL (Universal Authorization Language), and using adapters to implement parts of the UAL policy in the various platform access control systems. This is a very specific way of dealing with the particular problem addressed. At a more general level, the XACML standard described above has the potential to serve as a “lingua franca” for access control systems as it offers rich expressiveness and flexibility. Despite these features, the mapping to the XACML system is often far from trivial. In particular, for a source access control system in which primary authorizations can be subject to auxiliary constraints as discussed above, mapping to a single-authorization-query system like XACML presents the major problem that there is no mechanism for dealing with the auxiliary constraints. This problem is clearly illustrated by the following exemplary scenario based on conversion of a TAM access control policy to an XACML policy.
Assume that user ‘Alice’ can read the order for a new bicycle if she has the Read permission on object ‘Order/Bicycle’ and the Traverse permission on the parent object ‘Order’. Below is a simplified XACML policy with two rules which could be derived from the source TAM policy stating that Alice has Read permission on ‘Order/Bicycle’ and everyone in group ‘Dep44’ has Traverse permissions on ‘Order’.
<policy PolicyCombiningAlgorithm=“permit-overrides”> <rule <target <subject Alice>   <resource Order/Bicycle>   <action Read> </target></rule><rule <target <subject Dep44>   <resource Order>   <action Traverse> </target> </rule></policy>However, as discussed above, an XACML decision engine can be queried for a single authorization only: access_allowed(subject+,resource+,action), denoting that there may be one or more subjects and resources but exactly one action. Each subject being part of the requester is represented by some credentials, user id and group ids for example. By “Alice+Dep44” we denote the credentials Alice (user id) and Dep44 (group id). If a query is made of the form    access_allowed(Alice+Dep44,Order/Bicycle,Read)then this will not match the target for the rule expressing the auxiliary, Traverse authorization (Alice+Dep44,Order,Traverse) because the action and subject elements are different in the primary authorization triple. Note that neither
access_allowed(Alice+Dep44, {Order,Order/Bicycle},Read)
nor
access_allowed(Alice+Dep44, {Order,Order/Bicycle},Traverse)
is a possible solution for the access query because the action elements do not match. Thus, the only apparent solution would be to ask the XACML decision engine twice:
access_allowed(Alice+Dep44,Order/Bicycle,Read), and
access_allowed(Alice+Dep44,Order,Traverse)
and somehow ensure that access is only permitted if both queries are answered positively. This would require modification of the reference monitor, including devising a mechanism that allows the reference monitor to decide in which cases a single call (Read) is sufficient.
It will be clear from the foregoing that the presence of auxiliary constraints poses a major obstacle to conversion of an access control policy data structure to a single-authorization-query system.